prefetchRscResponse() adds entries to the shared prefetch cache without enforcing MAX_PREFETCH_CACHE_SIZE or sweeping expired entries. On link-heavy pages this can cause unbounded growth of both __VINEXT_RSC_PREFETCH_CACHE__ and __VINEXT_RSC_PREFETCHED_URLS__ (successful prefetches are never evicted unless navigated to). Consider reusing the same eviction/TTL sweep logic as storePrefetchResponse() before cache.set() (and deleting from prefetched when evicting).

consumePrefetchResponse() does not check PREFETCH_CACHE_TTL before returning a cached snapshot. As written, a prefetched RSC payload can be consumed arbitrarily long after it was fetched, which can serve stale UI and defeats the TTL constant/comment above. Suggest: if Date.now() - entry.timestamp >= PREFETCH_CACHE_TTL, delete the entry + prefetched marker and return null.

evictVisitedResponseCacheIfNeeded() evicts the oldest inserted entry (Map insertion order), but cache hits in getVisitedResponse() don't refresh recency. This makes the behavior FIFO rather than true LRU as described in the PR summary, and can evict an entry that was just used. If LRU is intended, update the entry's insertion order on read (delete+set) or maintain an explicit recency structure.

prefetchRscResponse() adds entries without enforcing MAX_PREFETCH_CACHE_SIZE. On link-heavy pages (hundreds of Link components), the prefetch cache can grow unbounded. The old storePrefetchResponse() has eviction logic — consider adding the same sweep+FIFO eviction here before cache.set().

Also, getPrefetchedUrls() entries for successfully-prefetched URLs are never evicted unless the URL is navigated to via consumePrefetchResponse(). If the user never visits those routes, they accumulate forever.

This returns the snapshot without checking TTL. A prefetched entry that's 5 minutes old will still be consumed here, serving stale UI. Consider:

PR summary says "LRU eviction" but this is FIFO — getVisitedResponse() doesn't refresh insertion order on cache hits. For true LRU, add visitedResponseCache.delete(rscUrl) + visitedResponseCache.set(rscUrl, cached) in getVisitedResponse() when returning a hit. Or just update the PR description to say FIFO — it's perfectly fine for a 50-entry cache.

For App Router RSC navigations, this pushes the URL into history before calling __VINEXT_RSC_NAVIGATE__, and then createNavigationCommitEffect inside navigateRsc will also attempt to push/replace history (guarded by window.location.href !== targetHref). The guard makes the second push a no-op in the normal case, but the intent would be clearer if navigateClientSide skipped the early push for RSC navigations and let the commit effect own it exclusively. The current code works but is fragile — a redirect could cause the URLs to diverge between the two push sites.

Setting module-level state (setBrowserTreeState) during render is a side effect that React Strict Mode or concurrent rendering could call multiple times. This works because setTreeState is referentially stable, but it would be more robust to use a useEffect or useRef pattern:

Not blocking, but worth considering for future React versions.

If the promise chain in updateBrowserTree rejects (e.g., createFromFetch fails after the snapshot is activated), activateNavigationSnapshot() has already incremented the counter but commitClientNavigationState() may never be called for this navigation, causing navigationSnapshotActiveCount to leak. The hooks would then permanently prefer stale snapshot values over useSyncExternalStore.

Consider wrapping renderNavigationPayload with a .catch() that calls commitClientNavigationState() to ensure the counter is always balanced.

Traversal ("traverse") returns cached entries regardless of expiresAt. This means back/forward can show arbitrarily old content if the user waits long enough. This is probably the right tradeoff for instant back/forward UX, but consider whether a generous upper bound (e.g., 30 minutes) would be appropriate to avoid very stale pages.

Good design: draining all effects ≤ the committed renderId handles the superseded-transition cleanup. One subtlety: for superseded renderIds (id < upToRenderId), you call commitClientNavigationState() which decrements navigationSnapshotActiveCount. This is correct since each was activated by renderNavigationPayload. Worth a brief inline comment noting that the 1:1 activate/commit pairing is maintained here.

This only increments; decrement happens in commitClientNavigationState(). The 1:1 pairing relies on drainPrePaintEffects cleaning up superseded navigations, and the catch block in navigateRsc calling commitClientNavigationState(). If you add error handling in renderNavigationPayload per my other comment, this becomes more robust. Consider adding a doc comment noting the pairing invariant.

Nit: the historyUpdateMode parameter is only meaningful for the commit effect inside navigateRsc. Since navigateClientSide already pushed/replaced the URL at lines 907-911 (before calling this), passing mode here is only needed so the commit effect knows to push again if the URL was changed by a redirect. This dual-purpose is confusing — a comment explaining why both the caller and callee touch history would help future readers.